Powertrain Matching User Interface

•

Background
The organization earlier had a set of extensive mathematical calculations, in an excel sheet. This included all the explanation, inputs and the results: mathematical and graphical. It is an informative tool for anyone who wants to study about the Powertrain Matching calculations in a detailed manner.

I joined the Trucks and Buses team at MBRDI, to develop a User Interface for Powertrain Matching, according to the employees' requirements. I took some reference from the other user interfaces that they had, and modified it according to this application. I carried out the following steps:

1. Reading and Understanding the Literature

2. Understanding requirements of the employees

3. Design and Deployment

1. Understanding the Literature

I had to carry out a Literature Review from various sources, such as Research Papers and Books for Powertrain Matching, to understand what factors affected Powertrain Matching. The excel sheet also assisted in determining the major factors that had to be taken into consideration.

2. Understanding Requirements of the Employees

To get a better understanding of the requirements, I had discussions with the employees. The major pain points that resulted in the development of this User Interface are:

1. Confusion while calculating values: Studying each point in the Excel file takes time and user might get confused by the barrage of information in front of them. The user interface is helpful for those who just want to explore the results obtained, by entering the relevant data without having to go through the extensive calculations.

2. Inefficiency of Design Process: When a product is designed, it travels back and forth from the design department to the validation department, till it is acceptable according to the standards and functionalities. Hence, the GUI helps in making the design more acceptable, according to the functionalities and standards, thus reducing the time taken to undergo final validation.

3. Design and Deployment

Keeping the above points in mind, I started making an initial flow of the processes that needed to be carried out. The flow of this interface for both the modules is as depicted below:

Flow of the User Interface

MODULE: 1

Gear- Ratio Calculations

Module 1: Gear Ratio Calculations

The gear ratios are calculated by taking in the necessary details from the user, through the GUI. The necessary constraints have been set in each section, so that the user is able to identify the range and types of values (alphabetical or numeric) they can enter.

Result Windows: Module 1

MODULE: 2

Vehicle Performance Calculations

Module 2: Vehicle Performance Calculations

The second module consists of the vehicle performance calculations, where the user has to select an engine and a gearbox from a set of given data, and enter all vehicle specifications. After entering these, the user gets the calculated performance in the form of maximum velocity and gradeability.

Result Windows: Module 2

Database Update Window

Apart from calculating the values, the User Interface also had to be capable of updating the existing database. This was done to ease the effort of going to the access database, and editing it every time you needed to use some new specifications. The functions that could be carried out, using the Database Update Window are depicted below:

Database Window: Flow of Processes

The database update window pops up, as the user selects "New" from any of the drop-downs, meant for extracting the specified Truck, Engine and Gear Box data from the database.

The database update window consists of 3 tabs, which can be used for updating database values of Truck Specifications, Engine Specifications, and Gear Ratios.

• Truck Specifications: For updating the truck specifications, the user just needs to enter the required specifications and press enter. After this, the user has to click the save button to save the changes.

• Engine Specifications: For the engine specifications update, the user can select any engine ID from the drop- box or else he/ she can create a new table by clicking on ‘Create Table’ after entering the ID for the engine in the drop- box. The user is not allowed to edit the table while viewing, editing can be done after clicking the ‘Edit Table’ button.

• Gear Ratios: The Gear Ratio Update tab functions the same as the Truck Update tab, and the editing or updating of data can be done in the same way.

CHALLENGES FACED

1. Incorporation of the database: for the incorporation of the database, it had to create a database, if not available. And at the same time, if the database was available, it had to read and display data in the data grid views and text boxes for further calculations. This was handled by using the Database Interaction Provider Class.

2. Tracing multiple curves, resulting in a redundant code: Another challenge came in, while tracing the curves. There are multiple curves for the traction and the gradient percentage graphs, which required repetitive codes. To make the code a bit concise, nested for loops and if- else statements have been used.

3. Error handling: The user had to be stopped from entering the wrong data, which would result in erroneous working of the program. Hence, message boxes have been incorporated to inform user of the erroneous data entered.

4. Populating data in Update Window: The update window was earlier used to take in data through datasets, which wouldn’t work on other Computers. Hence, the data update window was modified to update data directly from the data grid view.